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Status of this Memo 
This memo provides information for the Internet community. It does 
not specify an Internet standard. Distribution of this memo is 


unlimited. 
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1. INTRODUCTION 
1.1 The Internet Domain Name System 
The Domain Name System (DNS) provides for the translation between 


host names and addresses. Within the Internet, this means 
translating from a name such as "venera.isi.edu", to an IP address 


such as "128.9.0.32". The DNS is a set of protocols and databases. 
The protocols define the syntax and semantics for a query language to 
ask questions about information located by DNS-style names. The 


databases are distributed and replicated. There is no dependence on 
a single central server, and each part of the database is provided in 
at least two servers. 


The assignment of the 32-bit IP addresses is a separate activity. IP 
addresses are assigned by the Network Information Center 
(Hostmaster@NIC.DDN.MIL). 


In addition to translating names to addresses for hosts that are on 
the Internet, the DNS provides for registering DNS-style names for 
other hosts reachable (via electronic mail) through gateways or mail 
relays. The records for such name registration point to an Internet 
host (one with an IP address) that acts as a mail forwarder for the 
registered host. For example, the host "bah.rochester.ny.us" is 
registered in the DNS with a pointer to the mail relay 
"relayl.uu.net". This type of pointer is called an MX record. 


This gives electronic mail users a uniform mail addressing syntax and 
avoids making users aware of the underlying network boundaries. 


The reason for the development of the domain system was growth in the 
Internet. The host name to address mappings were maintained by the 
Network Information Center (NIC) in a single file, called HOSTS.TXI, 
which was FTPed by all the hosts on the Internet. The network 
population was changing in character. The timeshared hosts that made 
up the original ARPANET were being replaced with local networks of 
workstations. Local organizations were administering their own names 
and addresses, but had to wait for the NIC to make changes in 
HOSTS.TXT to make the changes visible to the Internet at large. 
Organizations also wanted some local structure on the name space. 

The applications on the Internet were getting more sophisticated and 
creating a need for general purpose name service. The idea of a 
hierarchical name space, with the hierarchy roughly corresponding to 
organizational structure, and names using "." as the character to 
mark the boundary between hierarcy levels. A design using a 
distributed database and generalized resources was implemented. 


The domain system provides standard formats for resource data, 
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standard methods for querying the database, and standard methods for 
name servers to refresh local data from other name servers. 


1.2 Top-Level Domains 


The top-level domains in the DNS are EDU, COM, GOV, MIL, ORG, INT, 
and NET, and all the 2-letter country codes from the list of 
countries in ISO-3166. 


Even though the intention was that any educational institution any 
where in the world could be registered under the EDU domain, in 
practice it has turned out with few exceptions only those in the 
United States have registered under EDU, similiary with COM (for 
commercial). In other countries, everything is registered under the 
2-letter country code, often with some subdivision. For example, in 
Korea (KR) the second level names are AC for academic community, CO 


for commercial, GO for government, and RE for research. However each 
country may go it's own way about organizing its domain, and many 
have. 


Their are no plans of putting all of the organizational domains .EDU 
.GOV .COM etc., under .US. 


However, there are some states registered in the .GOV domain (11 by 2 
letter code), and 3 by full names) 


ca.gov la.gov ohio.gov va.gov 
co.gov md.gov or.gov wa.gov 
hawaii.gov nc.gov sCc.gov 
ia.gov ny .gov texas.gov 
Other names sometimes appear as top-level domain names. Some people 
have made up names in the DNS style without coordinating or 
registering with the DNS management. Some names that typically 
appear are ".BITNET", ".UUCP", and two-letter codes for continents, 


such as ".NA" for North America (this conflicts with the official 
Internet code for Namibia). 


For example, the DNS style name "KA7EEJ.CO.USA.NA" is used in the 
amateur radio network. These addresses are never supposed to show up 
on the Internet but they do occasionally. The amateur radio network 
people created their own naming scheme, and it interferes sometimes 
with Internet addresses. 
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1.3 The US Domain 


The US Domain is an official top-level domain in the DNS of the 
Internet community. It is registered with the Network Information 
Center. The domain administrators are Jon Postel and Ann Westine 
Cooper at the Information Sciences Institute of the University of 
Southern California (USC-ISI). 


US is the IS0-3166 2-letter country code for the United States and 
thus the US Domain is established as a top-level domain and 
registered with the NIC the same way other country domains are. 


Because organizations in the United States have registered primarily 
in the EDU and COM domains, little use was initially made of the US 
domain. 


In the past, the computers registered in the US Domain were primarily 
owned by small companies or individuals with computers at home. 
However, the US Domain has grown and currently registers hosts in 
federal government agencies, state government agencies, K12 schools, 
community colleges, private schools, libraries, county agencies, and 
city utilities, to name a few. 


The administration of the US Domain was managed solely by the Domain 

Registrar in the past. However, due to the increase of hosts, 

administration of subdomains is being delegated to others. 

Any computer in the United States may be registered in the US Domain. 
2. NAMING STRUCTURE 

The US Domain hierarchy is based on political geography. The 

namespace under .US is the state namespace, then the city namespace, 

then organization or computer name and so on. 


For example: 


SPK.WA.US 
VANC.WA.US 


There is of course no problem with running out of names. 

The things that are named are individual computers. 

If you register now in one city and then move, the database can be 
updated with a new name in your new city, and a pointer can be set up 


from your old name to your new name. This type of pointer is called 
a CNAME record. 
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The use of un-registered names is not effective and causes problems 
for other users. Inventing your own name and using it without 
registering is not a good idea. 


2.1 State Codes 
The state codes are the two letter US Postal abbreviations. 
2.2 City Codes or Locality Names 


Cities may be named (designated) by their full name (spelled out with 
hyphens replacing spaces (e.g., Los-Angeles or New-York)), or by a 
city code. The first choice is the full city name, the second choice 
is the city codes from Western Union’s "City Mnemonics" list, anda 
third choice is a code for your city chosen by the applicant. 
However, it is very desirable that all users in the same city use the 
same designator for the city. 


Abbreviated city names are a good idea, particularly when the city 
name is long, as there is much to type already. One of the problems 
is that the city codes in the Western Union City Mnemonics list are 
sometimes not very good abbreviations. Users sometimes tend to 
prefer abbreviations that are commonly used already from that region. 
Such as SF for San Francisco, MPK for Menlo Park. 


Exceptions have been made in the abbreviations, even though this 
causes extra work to keep track of these abbreviations. One 
abbreviation for one city. Applicants are told what codes are 
currently in use, however, if a city code is not used yet, and they 
would prefer to use a different code that is more common among the 
natives, then the new code is allowed. However, once it’s 
registered, then everyone else who registers in that city will have 
to use that code or spell out the full city name. 


Some applicants have tried to get a copy of the Western Union City 
Mnemonics code list but it is no longer available from Western Union. 
However, we do have a copy but it is not online. If you are 
requesting an abbreviated city code please let us know and we will 
gladly look it up for you. 


2.3 Examples of Names 


For small entities like individuals or small businesses there is 
usually no problem with selecting locality based names. 


For example: Zuckys.Santa-Monica.CA.US 
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For large entities like large corporations with multiple facilities 
in several cities or states this often seems like a unreasonable 
constraint (especially when compared with the alternative of 
registering directly in the .COM domain). However, a company does 
have a headquarters office in a particular locality and so could 
register with that name. 


For example: IBM.Armonk.NY.US 


EXAMPLES OF THE NAMING STRUCTURE IN THE US DOMAIN 


PRIVATE (business or individual) 


Camp-Curry.Yosemite.CA.US <==== a business 
IBM.Armonk.NY.US <==== a business 
Dogwood.at1.GA.US <==== a business 
Geo-Petrellis.Culver-City.CA.US <==== a restaurant 
Zuckys-Santa-Monica.CA.US <==== a restaurant 
Joe-Josts.Long-Beach.CA.US <==== a bar 
Holodek.Santa-Cruz.CA.US <==== a personal computer 
FEDERAL 

Senate.FED.US <==== US Senate 

DOD.FED.US <==== US Defense Dept. 

DOT.FED.US <==== US Transportation Dept. 
USPS.FED.US <==== US Postal Service 

VA.FED.US <==== US Veterans Administration 
IRS.FED.US <==== US Internal Revenue Service 
Yosemite.NPS.Interior.FED.US <==== a federal agency 
STATE 

Senate.STATE.MN.US <==== state Senate 
House.STATE.MN.US <==== state House of Reps 
MDH.STATE.MN.US <==== state Health Dept. 
HUD.STATE.CA.US <==== state House and Urban Dev. Dept. 
DOT.STATE.MN.US <==== state Transportation Dept. 
Caltrans.STATE.CA.US <==== state Transportation Dept. 
DMV.STATE.CA.US <==== state Motor Vehicles Dept. 
Culver-City.DMV.STATE.CA.US <==== a local office of DMV 
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CITY | COUNTY 


Police.CITY.Culver-City.CA.US 
Fire-Dept.CITY.Los-Angeles.CA.US 
Fire-Dept .COUNTY.Los-Angeles.CA.US 


REGIONAL | DISTRICT | LIBRARY 


SCAQMD.DISTRICT.CA.US 
Bunker-Hill-Improvement.DISTRICT.LA. 


Huntington.LIB.LA.US 
Venice.LA-City.LIB.CA.US 
MDR.LA-County.LIB.CA.US 


K12 | cc | STATE UNIV | PRIVATE SCHO 


<==== a city departm 
<==== a city departm 
<==== a county depar 
<==== a region 

CA.US <==== a local 

<==== a private 
<==== a city lib 
<==== a county 1 


OLS 


Los-Angeles.UC.STATE.CA.US <=== 
Berkeley.UC.STATE.CA.US <=== 
Irvine.UC.STATE.CA.US <=== 
Santa-Cruz.UC.STATE.CA.US <=== 
Northridge.CSU.STATE.CA.US <=== 
Fullerton.CSU.STATE.CA.US <=== 
Sonoma .CSU.STATE.CA.US <=== 
SMCC.Santa-Monica.CC.CA.US <=== 


Trade-Tech.Los-Angeles.CC.CA.US <=== 


= UCLA 
= "CAL" 
= University of Cali 
= University of Cali 


= Calif. State. Univ. 
= Calif. State. Univ. 
= Calif. State. Univ. 


= a public community 
= a public community 


Hamilton.High.LA-Unified.K12.CA.US <==== a public 
Sherman-Oaks.Elem.LA-Unified.K12.CA.US <==== a public 
John-Muir.Middle.Santa-Monica.K12.CA.US <==== a public 
St-Monica.High.Santa-Monica.CA.US <==== a private 
St-Monica.Elem.Santa-Monica.CA.US <==== a private 
Crossroads-School.Santa-Monica.CA.US <==== a private 
Mary-Ellens.Montessori-School.LA.CA.US <==== a private 
Leland-Stanford-Jr-Univ.Stanford.CA.US <==== a private 
Loyola-Marymount-Univ.Los-Angeles.CA.US <==== a private 
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When appropriate, subdomains are delegated and partioned in various 
categories, such as: 


K12.<state>.US = kindegarten thru 12th grade 
CC.<state>.US = community colleges 
LIB.<state>.US = libraries 
STATE.<state>.US = state government agencies 
<org-name>.FED.US = federal government agencies 


The Appendix-I contains the current US Domain Names BNF, but in 
actuality, the names under these subdomains may vary according to the 
decision of the administrators of these subdomains. 


Some users would like names associated with a greater metropolitan 
area or region like the "Bay Area" or "Tri-Cities". One problem with 
this is that these names are not necessarily unique within a state. 
The best thing to do in this case is to use the larger metropolitan 
city in your host name. Cities and in some cases counties are used. 


3. REGISTRATION 
3.1 Requirements 


Anyone requesting to register a host in the US Domain is sent a copy 
of the US Domain policy and procedure, and must fill out a US Domain 
questionnaire. 


The US Domain template, is similar to the NIC Domain template 
however, it is not the same. To request a copy of the US Domain 
questionnaire, send a message to the US Domain registrar (us- 
domain@isi.edu). 


Note: If you are registering a name in a delegated zone 
(see Section 3.3.6). Please register with the 
contact for that zone. 


The key people must have electronic mailboxes (that work). Please 
provide all the information indicated in the "Administrator" and 
"Technical Contact" slot. This person will be the point of contact 


for any administrative and policy questions about the domain. 


The administrator is usually the person who manages the organization 
being registered. The technical contact can also be administrator, or 
the systems person, or someone who is familiar with the technical 
details of the Internet. The technical contact should have a valid 
working e-mail address. This is necessary in case something goes 
wrong. 
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It is important that your "Return-Path" and "From" field indicate an 
Internet style address. UUCP style addresses such as "hostl!user" 
will not work. This is fine within the UUCP world, but not the 
Internet. If you want people on the Internet to be able to send mail 
to you, your return path needs to be an Internet style address: such 
as hostl!user@internet.gateway.host or user@internet.gateway-.host. 


It is also possible to register through one of the Internet service 
providers that have established working relationships with the US 
domain administrator. 


If everything checks out, turn around time for registering a host is 
usually a day or two. The nameservers are updated anywhere from 12 
to 24 hours later. 


There are two ways to be registered in the US Domain, directly, or by 
delegation. 


3.2 Direct Entries 


Direct entry in the database of the US Domain appeals most to 
individuals and small companies. Fill out the application and send 
it directly to the US Domain administrator. If you are in an area 
where the zone is delegated to someone else your request will be 
forwarded to the zone administrator for your registration. 


3.2.1 UUCP Hosts 


Many applicants have hosts in the UUCP world. Some are one hop away, 
some two and three hops away from their "Internet Forwarder", this is 
ok. What is important is getting an Internet host to be your 
forwarder. If you do not already have an Internet forwarder, there 
are several businesses that provide this service for a fee, such as 
UUNET.UU.NET (postmaster@uunet.uu.net), PSI (postmaster@UU2.PSI.COM) 
and CERFNET (help@cerf.net). Sometimes local colleges in your area 
are already on the Internet and may be willing to act as an Internet 
Forwarder. You would need to work this out with the systems 
administrator we cannot make these arrangements for you. 


Although we work with UUCP service providers, the Internet US Domain 
registration is not affiliated with the registration of UUCP Map 


entries. The UUCP map entry does not provide us with sufficient 
information. If you do not have a copy of the US Domain 
questionnaire template, please send a message to: us-domain@isi.edu 
and request one. See Appendix-II. 
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This is not an appropriate registration for the US Domain. 


#N starl 

#S Amiga 2500; AmigaDOS 2.04; Dillon’s AmigaUUCP 1.15D 
O Starlight BBS 

#C Stephen Baker 

RE starl!sbaker 

$T +1 305 378 1161 

#P 1107 SW 200th St #303B Miami, Fl. 33157 

FL 25 47 N / 88 10 W [city] 


FR 

HU mthvax 

#W starl!sbaker (Stephen Baker); Mon Feb 24 19:58:24 EST 1992 
starl mthvax (DAILY) 


If you are registering your host as a central site for a USENET group 
where other UUCP sites will feed from you, that's fine. These UUCP 
sites do not need to register. If however, the other sites become a 
subdomain of your hostname, then we will need to register them 
individually or add a wildcard record. 


For example: bah.rochester.ny.us 
hostl.bah.rochester.ny.us 
host2.bah.rochester.ny.us 

3.2.2 NON-IP Hosts 
To use US Domain names for non-IP hosts, there must be a forwarder 
host that is an IP host. There must be an adminstrative agreement 


and a technical procedure for relaying mail between the non-IP host 
and the forwarder host. 


Your host is not an IP host but does talk directly with a host that 
is an IP host. 


"Forwarder" must be an IP host on the Internet. 


You must ask "forwarder" if they are willing to be the internet 
forwarder for "your-host". 


In the US Domain of the DNS data base there must be an entry like 
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this: 
"your-host" MX 10 "forwarder" 
This must be entered by the US Domain administrator. 
In the "forwarder" routing tables there must be information about 


"your-host" with a rule like: If I see mail for "your-host" I will 
send it via uucp by calling phone number "123-4567". 


Case 2 
In this case your hosts talks to another host that ... that talks to 
an IP host. In other words, there are multiple hops between your host 
and the Internet. 
Frattini + 

+---------- + +--------—- + 
|path-host |---UUCP----- forwarder | ----IP/TCP--| INTERNET | 
+---------—- + +--------- + | 

| +----------------- + 

UUCP 

ee ade + 
|your-host | 
FS + 


"Forwarder" must be an IP host on the internet. 


You must ask "forwarder" if they are willing to be the Internet 
Forwarder for "Your-Host". You must ask "path-host" to relay your 
mail. 


In the US Domain of the DNS DataBase there must be an entry like this: 
"your-host" MX 10 "forwarder" 
This must be entered by the US Domain Administrator. 


In the "forwarder" routing tables there must be information about 
"your-host" with a rule like: If I see mail for "your-host" I will 
send it via UUCP to "path-host" by calling phone number "123-4567". 
and "path-host" must also know how to relay the mail to "your-host". 


Note: It is assumed that "path-host" is already MXed to "forwarder". 
It is not appropriate to ask to MX "your-host" to "path-host" (this 
is sometimes called double MXing). The host on the right hand side 
of an MX entry must be a host on the Internet with an IP address 
(Sii 128. P.2:.:32) 0 
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3.3 Delegated Subdomains 


The administrator of the US Domain is responsible for the assignment 
of all the DNS names that end with ".US". Of course, one person or 
even one group can’t handle all this in the long run so portions of 
the name space are delegated to others. 


Delegation of cities, companies within cities, schools (K12), 
community colleges (CC), libraries (LIB), state government (STATE), 
and federal government agencies, departments, etc., is acceptable and 
practical. 


For a delegated portion of the namespace, for example a city, no 
alterations can be made to that name, no abbreviations added, etc. 
unless applied for. 


Sometimes there may be two people running name servers in the same 
city because different portions of the name space has been delegated 
to them. For example, someone may be delegated the <city>.<state>.US 
name space, and someone else from a state government agency may have 
the .STATE.<state>.US, portion. For example, Fred may run the name 
servers for Sacramento.CA.US and Joe may run the name servers for 
STATE.CA.US in Sacramento. 


If a company would like to have wildcard records added, or run their 
own name servers in a city that we have delegated name space to, this 
is ok. 


Delegation of the whole State namespace is not yet implemented. The 
delegated part of the name space is in the form of: 


. STATE.<state>.US. 
.K12.<state>.US. 
.CC.<state>.US. 
.LIB.<state>.US. 
.<org-name>.<city>.<state>.US. 
.CITY.<city-name>.<state>.US. 
.<org-name>.FED.US. 


3.3.1 Schools 
As schools begin to join the Internet, there ought to be a consistent 
scheme for naming them. A "K12" name branch has been established in 


each state in the US Domain for this purpose. 


Public schools are usually organized by districts which can be larger 
or smaller than a city or county. 
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It makes sense to name schools within districts. However districts 
often have the same name as a city or county so there has to be a way 
to distinguish a public school district name from some other type of 
locality name. The keyword "K12" is used for this. 


In some districts, the same school name is used at different levels, 
for example, Washington Elementary School and Washington High School. 
We suggest that when necessary the keywords "Elementary", "Middle", 
and "High" be used to distinguish these schools. These keywords 
would only be used when they are needed, if the school’s name is 
unique without such keywords don’t use them. 


Typical K12 school names currently used are like: 


IVY.PRS.K12.NJ.US 
DMHS.JCPS.K12.KY.US 
OHS.EUNION.K12.CA.US 
BOHS.BREA.K12.CA.US 


These names could be long. Given the large number of schools, 
organizing by school district and state seems appropriate. When 
there are many things to name some of the names must be long. 


In some cases there may be appropriate abbreviations that can be 
used. For example Hamilton High School in Los Angeles could be: 


Hami.Hi.LA.K12.CA.US 


Some School Examples: 


Hamilton.High.LA-Unified.K12.CA.US <== a public school 
Sherman-Oaks.Elem.LA-Unified.K12.CA.US <== a public school 
John-Muir.Middle.Santa-Monica.K12.CA.US <== a public school 
Crossroads-School.Santa-Monica.CA.US <== a private school 
SMCC.CC.CA.US <== a community college 
Northridge.CSU.STATE.CA.US <== a state university 


If a school has a bunch of PCs, then each PC should have a name. 
Suppose they are named "alpha", "beta", ... then if they belong to a 
school named "Lincoln.High.Lakewood.K12.CA.US" their names would be: 


alpha.Lincoln.High.Lakewood.K12.CA.US. 
beta.Lincoln.High.Lakewood.K12.CA.US 
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3.2.2 State Agencies 


US Domain namespace has been delegated to the state goverment 
agencies. For example, in the State of Minnesota, the subdomain is 
STATE.MN.US 


This means that the person running the namservers for state.mn.us are 
responsible for naming agencies, of the state govermnent. For 
example: 


State Agencies: 


Senate.STATE.MN.US <== State Senate 
MDH.STATE.MN.US <== Dept. of Health 
CALTRANS .STATE.CA.US <== Dept. of Transportation 
DMV.STATE.CA.US <== Dept. of Motor Vehicles 


3.3.3 Federal Agencies 


A federal namespace has been delegated to the federal government 
agencies. For example the subdomain for the Federal Reserve Bank of 
Minneapolis is MNPL.FRB.FED.US. Other examples are listed below. 


Federal Government Agencies: 


Senate.FED.US <==== US Senate 

DOD.FED.US <==== US Defense Dept. 

USPS.FED.US <==== US Postal Service 

VA.FED.US <==== US Veterans Administration 
TRS.FED.US <==== US Internal Revenue Service 
Yosemite.NPS.Interior.FED.US <==== A Federal agency 


3.3.4 Delegation Requirements 


When a subdomain is delegated, the following requirements must be 


met 
1) There must be a knowledgeable and competent technical contact, 
familiar with the Internet Domain Name System. This 
requirement is easily satisified if the technical contact 
already runs some other nameservers. 
2) Organizations requesting delegations must provide at least two 


independent (robust and reliable) DNS name servers in 
physically separate locations on the Internet. 
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The subdomain must accept all applicants on an equal basis. 


The subdomain must provide timely processing of requests. To 
do this it is helpful to have several individuals 
knowledgeable about the procedures so that the operations are 
not delayed due to one persons unavailability (for example by 
being on vacation). 


Delegation Procedures 


The procedure that is followed when a subdomain is delegated includes 
the following steps: 


1) 


Evaluate the technical contact’s experience with DNS. Make 
sure there is a need for the proposed delegation. Make sure 
the technical contact has the information about the US Domain 
and the suggested naming structure. 


Note: In the past there was the concept of a "coordinator" for 
a group or a club or "Domain Park". They would arrange to 
coordinate the registration of all the computers used by 
members of the club and forward all the information for the 
group to the US Domain Administrator. Most coordinators have 
moved into the position of administrator of that now delegated 
subdomain. 


Add the new technical contact to the "us-dom-adm" mailing list 
for distributing updates to the US Domain policies and 
procedures, or other pertinent information. 


Delete any hosts from our zone file that belongs in the newly 
delegated subdomain and make sure they now have the hosts in 
their zone file. 
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5) Send them a copy of the zone file so their initial zone file 


is identical to ours. 


mil.wi.us. 


mil.wi.us. 


spool.mu.edu. 


mil.wi.us. 


sophie.mscs 
solaria.mil 
solaria.mil 


nthomas.mil. 


nthomas.mil 


rwmke.mil.wi.us. 
rwmke.mil.wi.us. 
milestn.mil.wi.us. 
milestn.mil.wi.us. 
dawley.mil.wi.us. 
dawley.mil.wi.us. 


For example: 


SOA spool.mu.edu. manager.spool.mu.edu. 


86400 
920904 
28800 
14400 
3600000 
86400 ) 
86400 NS 
50400 A 
86400 NS 
.mu.edu. 50400 
.wi.us. 86400 
.wi.us. 86400 
wi.us. 86400 
.wi.us. 86400 
86400 
86400 
86400 
86400 
86400 
86400 


¿serial 
¡refresh 
;retry 
¡expire 
;minim 


spool.mu.edu. 
134.48.1.31 
sophie.mscs.mu.edu. 


134.48.4.6 
Sun 3/60 SunOs 
10 spool.mu.edu. 


DS wp 
2 
"j 
O 
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X 

INFO 386 Clone DOS 
MX 10 spool.mu.edu. 
HINFO UNIX PC UNIX 
MX 10 spool.mu.edu. 
HINFO PC AT ENIX 
MX 10 spool.mu.edu. 
HINFO 386 Clone DOS 
MX 10 spool.mu.edu. 
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The US Domain zone file must have the following records, 
showing the name, address, e-mail, and phone number of the 
technical contact for the delegated subdomain and the name of 
the delegated name space and the names of the nameservers. 


PEF PAT BARA AMEN ETETE ER FEE ARAN ANNE NOIA AN ANO ESE ERA EN EN ARAN AAN EE RANA 
i 

;Delegated zone: .mil.wi.us 

; Contact: Steven Goodman 

; manager@spool.mu.edu 

; Marquette University 

F (414) 288-6734 


mil.wi.us. 604800 NS SPOOL.MU.EDU. 
604800 NS SOPHIE.MSCS.MU.EDU. 


; A glue record is not needed this time. Glue records are 
; needed when the name of the server is a subdomain of the 
; delegated domain. 


CO EP EOE PE IEE ER CE ER EP AER OE EE IEE EIS BEE EPA EIA IEE BIE EEL EP ESE PE FOE 


Check to see that delegated subdomain name servers are up and 
running, and make sure the delegated hosts are installed in 
their zone file. Now delete any hosts from the US Domain zone 
file that belongs in the newly delegated subdomain. 


Inform the technical contact of the newly delegated subdomain 
that wildcard records are allowed in the zone file under the 

organizational subdomain but no wildcard records are allowed 

under the "city" or "state" domain. 
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3334-6 Subdomain Contacts 


Approximately 680 individual hosts are registered, but we have 
delegated the following portions of the namespace. We do not know 
how many hosts are registered under each of these subsdomains. 


DELEGATED ZONE CONTACT 

TUCSON.AZ.US leonard@arizona.edu 

SF.CA.US sf-hostmaster@apple.com 
PREMENOS.SF.CA.US jenkins@premenos.sf.ca.us 
SCVL.CA.US sinster@scintilla.capitola.ca.us 
SANTA-CRUZ.CA.US sinster@scintilla.capitola.ca.us 
APTOS.CA.US sinster@scintilla.capitola.ca.us 
CAMPBELL.CA.US sinster@scintilla.capitola.ca.us 
CAPITOLA.CA.US sinster@scintilla.capitola.ca.us 
FELTON.CA.US sinster@scintilla.capitola.ca.us 
ZAYANTE.CA.US sinster@scintilla.capitola.ca.us 
BOULDER-CREEK.CA.US sinster@scintilla.capitola.ca.us 
DARWIN.PTVY.CA.US brian@angband.stanford.edu 
LOGAN-HS.UNIONCITY.CA.US cjw@marmot .nersc.gov 
BOULDER.CO.US trent@XOR.COM 

COLOSPGS.CO.US trent@XOR.COM 

DENVER.CO.US trent@XOR.COM 

DVR.CO.US trent@XOR.COM 

CHI.IL.US matt@oddjob.uchicago.edu 
EUGENE.OR.US meyer@oregon.uoregon.edu 
SPRINGFIELD.OR.US meyer@oregon.uoregon.edu 
MULTNOMAH.LIB.OR.US brianw@polaris.admin.ogi.edu 
PGH.PA.US ecd@CERT.ORG 

SPK.WA.US root@dogear.spk.wa.us 

MIL.WI.US manager@spool.mu.edu 

ATL.GA.US charvey@gatech.gatech.edu 
Mt-PARK.GA.US charvey@gatech.gatech.edu 
CLARKSTON.GA.US charvey@gatech.gatech.edu 
STATE.MN.US dfazio@mr.net 

MNPL.FRB.FED.US dfazio@mr.net 

K12.CA.US mdm@NIC.CSU.NET 

CC.CA.US mdm@NIC.CSU.NET 

K12.MI.US sandra.s.waite@um.cc.umich.edu 
K12.TX.US bmanning@is.rice.edu 

K12.NJ.US becker@nisc.jvne.net 

K12.MS.US fwp@msstate.edu 
dmhs.jcps.K12.KY.US lentner@sura.net 

TIES .K12.MN.US dfazio@mr.net 
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The following MD.US counties have been delegated to 
(butler@brl.mil). 


AL.MD.US. Allegany 
AA.MD.US. Anne Arundel 
BA.MD.US. Baltimore 
CAL.MD.US. Calvert 
CAR.MD.US. Caroline 
CE.MD.US. Cecil 
CH.MD.US. Charles 
DO.MD.US. Dorchester 
FR.MD.US. Frederick 
GA.MD.US. Garrett 
HA.MD.US. Harford 
HO.MD.US. Howard 
KE.MD.US. Kent 
MO.MD.US. Montgomery 
PG.MD.US. Prince George"s 
QA.MD.US. Queen Anne’s 
SM.MD.US. St. Mary’s 
SO.MD.US. Somerset 
TA.MD.US. Talbot 
WA.MD.US. Washington 
WI.MD.US. Wicomico 
WO.MD.US. Worcester 


DATABASE INFORMATION 
4.1. Name Servers 


Name servers are the repositories of information that make up the 
domain database. The database is divided up into sections called 
zones, which are distributed among the name servers. While name 
servers Can have several optional functions and sources of data, the 
essential task of a name server is to answer queries using data in 
its zones. The response to a query can always be generated using 
only local data, and either contains the answer to the question or a 
referral to other name servers "closer" to the desired information. 


A given zone will be available from several name servers to insure 
its availability in spite of host or communication link failure. 
Every zone is required to be available on at least two servers, and 
many zones have more redundancy than that. 
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The US Domain is currently supported by six name servers. 


venera.isi.edu 
ns.isi.edu 
ns.hercules.csl.sri.com 
nnsc.nsf.net 

ns.uu.net 

adm.brl.mil 


4.2 Zone Files 


A "zone" is a registry of domains kept by a particular organization. 
A zone registry is "authoritative", that is, the master copy of the 
registry is kept by the zone organization, and this copy is, by 
definition, always up-to-date. Copies of this registry may be 
distributed to other places and kept in caches, but these caches are 
not authoritative, and may be out-of-date. 


Every zone has at least one node, and hence domain name, for which it 
is authoritative, and all of the nodes in a particular zone are 
connected. Given the tree structure, every zone has a highest node 
which is closer to the root than any other node in the zone. The 
name of this node is often used to identify the zone. The data that 
describes a zone has four major parts: 


1) Authoritative data for all nodes within the zone. 


2) Data that defines the top node of the zone 
(can be thought of as part of the authoritative data). 


3) Data that describes delegated subzones, i.e., cuts 
around the bottom of the zone, 


4) Data that allows access to name servers for subzones 
(sometimes called "glue" data). 


The zone administrator has to maintain the zones at all the 
namservers which are authoritative for the zone. When the changes 
are made they must be distributed to all of the name servers. 


Copies of the zone files are not available unless you are on the 
Internet. To look at the zone files use the "dig" program of the DNS 
domain name system. 


dig @nshost host-your-checking axfr 
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4.3 Resource Records 


Records in the zone data files are called resource records (RRs). 
The standard Resource records (RR) are specified in STD 13, RFC 1034 
and STD 13, RFC 1035 (3,4). An RR has a standard format as shown. 


<name> [<ttl>] [<class>] <type> <data> 


The first field is always the name of the domain record. The second 
field is an optional time to live field. This specifies how long 
this data will be stored in the data base. The third field is the 
address class; the class field specifies the protocol group most 
often this is the Internet class "IN". The fourth field states the 
type of the resource record. The fields after that are dependent on 
the Type of RR. The fifth field is the data field which is defined 
differently for each type and class of data. Here is a list of the 
current commonly used types. 


SOA Start of Authority 
NS Name Server 
A Internet Address 


CNAME Canonical Name (nickname pointer) 
HINFO Host Information 


WKS Well Known Services 
MX Mail Exchanger 
PTR Pointer 


What do the fields mean? 


foo.LA.CA.US. 604800 MX 10 Venera.ISI.EDU. 
(1) (2) (3) (4) (5) 

1) domain name 

2) time to live information 

3) mail exchanger record 

4) preference value to determine (if more than one 


forwarder) which mailer to use first, lower number 
higher preference 
5) the Internet forwarding host. 
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4.3.1 A Records 


Internet (IP) Address. The data for an "A" record is an Internet 
address in a dotted decimal form. A sample "A" record might look 
like: 
venera.isi.edu. A 128.9.0.32 
(name) (A) (address) 


The name field is the machine name, and the address is the network 
address. There should be only one "A" record for each address of a 
host. 


4.3.2 CNAME Records 


Canonical Name resource record, CNAME, specifies an alias fora 
canonical name. This is essentially a pointer to the official name 
for the requested name. All other RRs appear under this official 
name. A machine named FERNWOOD.MPK.CA.US may want to have the 
nickname ANTERIOR.MPK.CA.US. In that case, the following RR would be 
used: 


anterior.mpk.ca.us. CNAME fernwood.mpk.ca.us. 
(alias nickname) (canonical name) 


Nicknames (the name associated with the RR is the nickname) may be 
added for awhile when a host changes its name, usually because it 
moves to another state. It helps to have this CNAME pointer so if 
any mail comes to the old address it will get forwarded to the new 
one. There cannot be any other RRs associated with a nickname of the 
same class. 


4.3.3 MX Records 


Mail Exchanger records, MX, are used to specify a machine that knows 
how to deliver mail to a machine that is not directly connected to 
the Internet. For example, venera.isi.edu is the mail gateway that 
knows how to deliver mail to foo.la.ca.us, but other machines on the 
network cannot deliver mail directly to foo.la.ca.us. These two 
machines may have a private connection or use a different transport 
medium (such as uucp). The preference value (10) is the order that a 
mailer should follow when there is more than one way to deliver mail 
to a single machine. The lower the number the higher the preference. 


foo.LA.CA.US. 604800 MX 10 Venera.ISI.EDU. 
foo.LA.CA.US. 604800 MX 20 relayl.uu.net. 
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4.3.4 HINFO Records 


Host information resource records, HINFO is for host specific data. 
This lists the hardware and operating system that are running at the 
listed host. It should be noted that a space separates the hardware 
information and the operating system information. If you want to 
include a space in the machine name you must quote the name. Host 
information is not specific to any class, so ANY may be used for the 


address class. There should be one HINFO record for each host. 
acb.la.ca.us. HINFO VAX-11/780 UNIX 
(Hardware) (Operating System) 


The official HINFO types can be found in the latest Assigned Numbers 
RFC, the most recent edition being RFC 1340. The hardware type is 
called the Machine Name, and the software type is called the System 
Name. 


The information users supply about this is often inconsistent or 
incomplete. Please follow the terms in the current "Assigned 
Numbers". 


4.3.5 PTR Records 


A Domain Name Pointer record, PTR, allows special names to point to 
some other location in the domain data base. These are typically 
used in setting up reverse pointers for the special IN-ADDR.ARPA 
domain. PTR names should be unique to the zone. 


0.0.9.128.in-addr.arpa PTR isi-net.isi.edu. 
(special name) (real name) 


A PTR record is to be added to the IN-ADDR.ARPA domain for every A 
record registered in the US Domain. These PTR records need to be 
added by the administrator of the network where the host is 
connected. The US Domain administration does not administer the 
network and cannot make these entries in the DNS database. 


4.4 Wildcards 


The wildcard records are of the form "*.<anydomain>", where 
<anydomain> is any domain name. The wildcards potentially apply to 
descendents of <anydomain>, but not to <anydomain> itself. 


For example, suppose a large company located in California with a 
large, non-IP/TCP, network wanted to create a mail gateway. If the 
company was called DWP.LA.CA.US, and the IP/TCP capable gateway 
machine (Internet forwarder) was called ELROY.JPL.NASA.GOV, the 
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following RRs might be entered into the .US zone. 


dwp.la.ca.us MX 10 ELROY.JPL.NASA.GOV 
*.dwp.la.ca.us MX 10 ELROY.JPL.NASA.GOV 


The wildcard record *.DWP.LA.CA.US would cause an MX query for any 
domain name ending in DWP.LA.CA.US to return an MX RR pointing at 
ELROY.JPL.NASA.GOV. The entry without the "*" is needed so the host 
dwp can be found. 


In the US Domain, wildcard records are allowed in our zone files 
under the organizational subdomain (and where noted otherwise) but no 
wildcard records are allowed under the "City" or "State" domain. 


The authors strongly believe that it is in everyone’s 
interest and good for the Internet to have each host 
explicitly registered (that is, we believe that wildcards 
should not be used), we also realize that not everyone 
agrees with this belief. Thus, we will allow wildcard 
records in the US Domain under groups or organizations. 
For example, *.DWP.LA.CA.US. 


The reason we feel single entries are the best is by the mere 
fact that if anyone wanted to find one of the hosts in the 
domain name system it would be there, and problems can be 
detected more easily. When using wildcards records all the 
hosts under a subdomain are hidden. 
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APPENDIX-I: US DOMAIN NAMES BNF 


<us-domain-name> 2:35 


<us-name> = 


<state-code> LS 


<state-name> 235 


<fed-name> 235 


<locality> 23S 


<local-name> 235 


<state-agency-name> 


<us-name><dot><us> 


<state-name><dot><state-code> | 
<fed-name><dot><fed> 


<the two-letter code of a state from the 
zip code directory> 


<local-name><dot><locality> | 
<state-agency-name><dot><state> | 
<regional-agency-name><dot><agency> 


<the dotted hierarchical name of a US 
federal government agency> 


<the full name of a city from the 
zip code directory> | 
<a short code name for a city> | 
<the full name of a county, township, 
or parish> | 
<other well known and commonly used 
locality name> 


<entity-name> | 
<city-name><dot><city> | 
<county-name><dot><count y> 
<local-agency-name><dot><agency> 


<the dotted hierarchical name of a state 
government agency> 


<regional-agency-name> 


<entity-name> 


<city-name> 


Cooper & Postel 


1992 


::= <the dotted hierarchical name of a special 
agency or district not an element of the 


state government and typically larger than 
a single city or county, for example, the 
Southern California Air Quality Management 


District> 


<the dotted hierarchical name of an entity 


within a city, for example: a company, 


business, private school, club, organization, 


or individual> 


<the dotted hierarchical name of a city 
government agency> 
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<county-name> ::= <the dotted hierarchical name of a county, 
township, or parish government agency> 


<local-agency-name> <the dotted hierarchical name of a special 
agency or district not an element of a 
city or county government and typically 
equal or smaller than a single city or 
county, for example, the Bunker Hill 


Improvement District> 


<city> ::= "CITY" 

<county> ::= "COUNTY" "TOWNSHIP" "PARISH" 

<dot> EO Ngn 

<fed> = "FED" 

<agency> ::= "AGENCY" | "DISTRICT" | "Ki2". | "cc" | "LIB" 
<state> ::= "STATE" | "COMMONWEALTH" 

<us> ::= "Us" 

Note: "K12" may be used for public school districts, only. 


and "CC" may be used only for public community colleges, 
and "LIB" can only be used by libraries. 


Cooper & Postel [Page 27] 


RFC 1386 The US Domain December 1992 


APPENDIX-II: US DOMAIN QUESTIONNAIRE FOR HOST ENTRY 


To register a host in the US domain, the following information must be 
sent to the US Domain Registrar (Us-Domain@ISI.EDU). Questions may be 
sent by electronic mail to the above address, or by phone to 

Ann Cooper (310-822-1511). 


(1) The name of the top-level domain to join. 


For example: US 


(2) The name of the administrative head of the organization, including 
title, mailing address, phone number, organization, and network 
mailbox. This is the contact point for administrative and policy 
questions about the domain. In the case of a research project, 
this should be the principal investigator. 


For example: 
Administrator 


Organization The NetWorthy Corporation 

Name Penelope Q. Sassafrass 

Title President 

Mail Address The NetWorthy Corporation 
4676 Andrews Way, Suite 100 
Santa Clara, CA 94302-1212 

Phone Number (415) 123-4567 

Net Mailbox Sassafrass@ECHO.TNC.COM 
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(3) 


The name of the technical contact for the entry, including title, 
mailing address, phone number, organization, and network mailbox. 
This is the contact point for problems concerning the domain or 
zone, as well as for updating information about the domain or zone. 


For example: 
Technical Contact 


Organization The NetWorthy Corporation 

Name Ansel A. Aardvark 

Title Executive Director 

Mail Address The NetWorthy Corporation 
4676 Andrews Way, Suite 100 
Santa Clara, CA. 94302-1212 

Phone Number (415) 123-6789 

Net Mailbox Aardvark@ECHO.TNC.COM 


The name of the host. This is the name that will be used in tables 
and lists associating the domain with the domain server addresses. 
[While, from a technical standpoint, domain names can be quite long 
(programmers beware), shorter names are easier for people to cope 
with.] 


For example: NetWorthy.Santa-Clara.CA.US 


Or: Alpha.NetWorthy.Santa-Clara.CA.US 
Beta.NetWorthy.Santa-Clara.CA.US 


If this machine is not directly on the internet, how does it 
communicate with the Internet. Through UUCP, CREN, etc? Which 
forwarding host? 


For example: The host "Networthy.Santa-Clara.CA.US" uses UUCP 
to connect to "RELAY.ISI.EDU" which is an Internet host. 


The administrator of RELAY.ISI.EDU must agree to be the 
forwarding host for Networthy.Santa-Clara.CA.US, and the 
forwarding host must know a delivery method and route to it. 
No double MXing. 


Cooper & Postel [Page 29] 


RFC 1386 The US Domain December 1992 


If you are requesting an indirect connection, that is, a Mail 
Exchanger (MX) record, what is the name and mailbox of the 
administrator of the forwarding host. 


For example:John Smith 
jS@RELAY.ISI.EDU 


Please describe your organization briefly. 


For example: The NetWorthy Corporation is a consulting 
organization of people working with UNIX and the C language in an 
electronic networking environment. It sponsors two technical 
conferences annually and distributes a bimonthly newsletter. 


What Domain Name System (DNS) Resource Records (RR) and values are 
to be entered. 


a A Internet Address (internet hosts only) 

b HINFO Host Information, Machine System 

€ WKS Well Known Services, Protocols, Ports (internet hosts only) 
d MX Mail Exchanger (required for UUCP, and CREN hosts) 


An example of RRs for an internet host. 


NetWorthy.Santa-Clara.CA.US IN A 128.932 123 
IN HINFO SUN-3/110C UNIX 
IN MX 10 ISI.EDU 
IN WKS 128.9.3.123. UDP (echo 
tftp) 
IN WKS 128.9.3.133. TCP (telnet 
ftp 
tftp 
finger) 
An example of RRs for a non-internet host. 
Beta.NetWorthy.Santa-Clara.CA.US MX 10 RELAY.ISI.EDU 


HINFO SUN-3/110C UNIX 
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(8) Where is the IN-ADDR pointer record to be entered. (For internet 
hosts only.) It is your responsibility to see that this is done. 
Contact the administrator of the IP network your host is on. The 
US Domain administration does not administer the network and cannot 
make these entries in the DNS database. 


For example: 
123.3.9.128.IN-ADDR.ARPA. PTR NetWorthy.Santa-Clara.CA.US 
Who is the contact for the zone of the IN-ADDR.ARPA data, where 


this record will be entered? 


(9) What Time to Live (TTL)? TTL is the time (in seconds) that a 
resolver will use the data it got from the domain server before it 
asks it again for the data. A typical TTL is One Week 604800. 
(NOTE: TTL is not applicable to non-Internet hosts.) 

For example: 


One Week 604800 
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